Concurrent mutation of isolated object graphs

ABSTRACT

Fine-grained parallelism within isolated object graphs is used to provide safe concurrent operations within the isolated object graphs. One example provides an abstraction labeled IsolatedObjectGraph that encapsulates at least one object graph, but often two or more object graphs, rooted by an instance of a type member. By encapsulating the object graph, no references from outside of the object graph are allowed to objects inside of the object graph. Also, the encapsulated object graph does not contain references to objects outside of the graphs. The isolated object graphs provide for safe data parallel operations, including safe data parallel mutations such as foreach loops. In an example, the ability to isolate the object graph is provided through type permissions.

CROSS-REFERENCE TO RELATED APPLICATIONS

This patent application is a continuation of Ser. No. 12/429,874, filedApr. 24, 2009, entitled, “CONCURRENT MUTATION OF ISOLATED OBJECTGRAPHS,” which is incorporated herein by reference.

BACKGROUND

Concurrent programming for shared-memory multiprocessors can include theability for multiple threads to access the same data. The multiplethreads execute on multiple processors, multiple processor cores, orother classes of parallel hardware architecture involving a memorysystem shared among the processors. The shared-memory model is the mostcommonly deployed method of multithreaded communication. In suchsystems, concurrent threads can attempt to access and modify the samedata in the shared-memory and perform side effects on this data and thereal world through input/output. This can lead to race conditions andother undesired effects in concurrent programming and the stored data.

A major difficulty in implementing concurrent programming involvesprotecting the state of concurrently accessed data to avoid theseundesired effects. Developers often rely on a form of synchronizationfor concurrency safety. Synchronization often involves the use of locks,which is a form of pessimistic concurrency control mechanism thatprevents all other threads from accessing certain data while one threadis already doing so. Locks provide synchronization often at the expenseof performance and scalability. Newer synchronization technologies, suchas those based on optimistic concurrency control (like SoftwareTransaction Memory), provide far superior performance and scalabilitythan locks. But all contemporary synchronization mechanisms, evenoptimistic concurrency control systems, eventually provide scalabilityissues in concurrent programming: when threads wait for another,scalability drops; shared-memory systems use caches whose performancedrops significantly when threads share access to memory; and so on.

SUMMARY

This summary is provided to introduce a selection of concepts in asimplified form that are further described below in the DetailedDescription. This summary is not intended to identify key features oressential features of the claimed subject matter, nor is it intended tobe used to limit the scope of the claimed subject matter.

The examples are directed to fine-grained parallelism within isolatedobject graphs to provide safe concurrent mutation of data within theisolated object graphs. One example provides an abstraction labeledIsolatedObjectGraph<T> to encapsulate a whole object graph rooted by asingle object of type T. By encapsulating the object graph, noreferences from outside of the object graph are allowed to point atobjects inside of the object graph, and similarly, the object graph doesnot contain references to objects outside of the graph. The isolatedobject graphs provide for safe data parallel operations, including safedata parallel mutations via foreach loops. In one example, an imperativeframework provides for statically proving the object graph to beisolated. The object graph can be statically proven to continue to beisolated after objects within the object graph are run, read, and/orwritten. In an example, the ability to isolate the object graph isprovided through type permissions.

BRIEF DESCRIPTION OF THE DRAWINGS

The accompanying drawings are included to provide a furtherunderstanding of embodiments and are incorporated in and constitute apart of this specification. The drawings illustrate embodiments andtogether with the description serve to explain principles ofembodiments. Other embodiments and many of the intended advantages ofembodiments will be readily appreciated as they become better understoodby reference to the following detailed description. The elements of thedrawings are not necessarily to scale relative to each other. Likereference numerals designate corresponding similar parts.

FIG. 1 is a block diagram illustrating an example computing system.

FIG. 2 is a block diagram illustrating one example embodiment of amanaged environment operating on a computing system, such as thecomputing system of FIG. 1.

FIG. 3 is a flow diagram illustrating an example embodiment of a methodof a managed environment, such as the managed environment of FIG. 2.

FIG. 4 is a block diagram illustrating an example embodiment of aninterface of a method of a managed environment, such as the managedenvironment of FIG. 2.

FIG. 5 is a flow diagram illustrating an example embodiment of a methodof a managed environment, such as the managed environment of FIG. 2,where the embodiment of the method can be implemented with an embodimentof the interface of FIG. 4.

DETAILED DESCRIPTION

In the following Detailed Description, reference is made to theaccompanying drawings, which form a part hereof, and in which is shownby way of illustration specific embodiments in which the invention maybe practiced. In this regard, directional terminology, such as “top,”“bottom,” “front,” “back,” “leading,” “trailing,” etc., is used withreference to the orientation of the Figure(s) being described. Becausecomponents of embodiments can be positioned in a number of differentorientations, the directional terminology is used for purposes ofillustration and is in no way limiting. It is to be understood thatother embodiments may be utilized and structural or logical changes maybe made without departing from the scope of the present invention. Thefollowing detailed description, therefore, is not to be taken in alimiting sense, and the scope of the present invention is defined by theappended claims. It is to be understood that the features of the variousexemplary embodiments described herein may be combined with each other,unless specifically noted otherwise.

FIG. 1 illustrates an exemplary computer system that can be employed asan operating environment includes a computing device, such as computingdevice 100. In a basic configuration, computing device 100 typicallyincludes a processor architecture having at least two processing units,i.e., processors 102, and memory 104. Depending on the exactconfiguration and type of computing device, memory 104 may be volatile(such as random access memory (RAM)), non-volatile (such as read onlymemory (ROM), flash memory, etc.), or some combination of the two. Thisbasic configuration is illustrated in FIG. 1 by dashed line 106. Thecomputing device can take one or more of several forms. Such formsinclude a personal computer, a server, a handheld device, a consumerelectronic device (such as a video game console), or other.

Computing device 100 can also have additional features or functionality.For example, computing device 100 may also include additional storage(removable and/or non-removable) including, but not limited to, magneticor optical disks or solid state memory, or flash storage devices such asremovable storage 108 and non-removable storage 110. Computer storagemedia includes volatile and nonvolatile, removable and non-removablemedia implemented in any suitable method or technology for storage ofinformation such as computer readable instructions, data structures,program modules or other data. Memory 104, removable storage 108 andnon-removable storage 110 are all examples of computer storage media.Computer storage media includes, but is not limited to, RAM, ROM,EEPROM, flash memory or other memory technology, CD-ROM, digitalversatile discs (DVD) or other optical storage, magnetic cassettes,magnetic tape, magnetic disk storage or other magnetic storage devices,universal serial bus (USB) flash drive, flash memory card, or otherflash storage devices, or any other medium that can be used to store thedesired information and that can be accessed by computing device 100.Any such computer storage media may be part of computing device 100.

Computing device 100 includes one or more communication connections 114that allow computing device 100 to communicate with othercomputers/applications 115. Computing device 100 may also include inputdevice(s) 112, such as keyboard, pointing device (e.g., mouse), pen,voice input device, touch input device, etc. Computing device 100 mayalso include output device(s) 111, such as a display, speakers, printer,or the like.

The computing device 100 can be configured to run an operating systemsoftware program and one or more software applications, which make up asystem platform. In one example, the computing device 100 includes asoftware component referred to as a managed, or runtime, environment.The managed environment can be included as part of the operating systemor can be included later as a software download. The managed environmenttypically includes pre-coded solutions to common programming problems toaid software developers to create software programs, such asapplications, to run in the managed environment. The managed environmenttypically includes a virtual machine that allows the softwareapplications to run in the managed environment so that the developersneed not consider the capabilities of the specific processors 102.

The runtime is used only as an example. The embodiments of thedisclosure below are not, however, confined to be used in a managedexecution environment and are not confined to any runtime requirement.Rather, the embodiments are implemented in a type system. Accordingly,it is contemplated that embodiments can be implemented in C++ or othernative code.

FIG. 2 illustrates an example embodiment of a managed, or runtime,environment 120 suitable for operation with a computing device, such asthe computing device 100. Particular current examples of managedenvironment frameworks include that sold under the trade designation of.Net from Microsoft Corp. of Redmond, Wash., United States, and Javafrom Sun Microsystems, Inc. of Santa Clara, Calif., United States, aswell as others. The managed environment 120 is configured to acceptprograms written in a high-level compatible code of one or moreprogramming languages 122. For example, the managed environment canaccept programs written in programming languages such as C-sharp (C#)code 124, a visual basic type language such as VB.NET code 126, and aJava type language (such as J-sharp) 128. Compilers 130 are configuredto compile each compatible code 124, 126, 128. The compiled code can beprovided to an infrastructure 132 that describes an executable code anda runtime environment that describes a number of runtimes. An exampleinfrastructure is Common Language Infrastructure (CLI). Theinfrastructure receives the compatible languages and converts them to asecond and platform-neutral intermediate language 134, such as CommonIntermediate Language (CIL). The intermediate language is provided to aruntime compiler 136, such as the Microsoft Common Language Runtime(CLR) in the .NET framework, that compiles the intermediate languageinto a machine readable code 138 that can be executed on the currentplatform or computing device.

To enable the runtime to provide service to the managed code, languagecompilers emit metadata that describes, among other things, the types inthe code. A great majority of programming languages explicitly includethe notion of “data types” and “type systems” although differentlanguages may include different terminology to describe these features.A data type is an attribute of a corresponding data that describes somefeatures about the data such as a set of legal values and allowableoperations on the values. A data type is metadata for the correspondingdata. A type gives meaning to data because hardware of the computingdevice 100 does not make a distinction between memory addresses,instruction code, integers, floating point numbers, and the like. A typesystem associates the type or types with each program value and attemptsto prove that no program errors occur. This is often verified with thelanguage complier 136, such as the C# compiler, CLR verifier, or C++compiler.

Examples below describe a platform-wide capability for controlling sideeffects through an additional facet of the type system. Side effects arepermitted when state is confined within a thread, which permits a formof concurrency safety without synchronization. Isolation support enablesthe type system to guarantee that certain state remains as it existedprior to a method call and to grant permission to mutate certain state.In the examples, an object reference (e.g. passed as an argument) can betagged with an isolation permission modifier from a set of a pluralityof isolation permission modifiers, stating what recipients of thereference can do with the object.

Other examples of controlling side effects exist, but none involveeffect permissions to be carried out on typed references. Effectssystems try to categorize the side effects allowed with a particularmethod. Functional programming languages, like Haskell, approach theproblem in a wholly different way because they disallow side effectsaltogether. Haskell allows for the simulation of side-effects using a“state monad” and combined with the do combinator. This provides theillusion of an imperative style of programming, but it is modeled withfunctional monads and continuations.

Unlike the Haskell example, the disclosed examples operate on imperativeprogramming languages such as C++, C#, and Java. Imperative programmingis a computer programming paradigm that describes computation as aseries of statements that change a program state modeling the realcapabilities of traditional von Neumann architectures more directly.Imperative programming can be contrasted with functional programming,which avoids state and mutable data. For example, purely functionalprograms have no side effects, which are modifications of some statewhile returning a value. Imperative programming uses side effects toimplement state and input/output functions.

State isolation and definition of methods that preserve state isolationcan be provided in this example through type permissions. FIG. 3illustrates an example embodiment of a method 300 that can beimplemented as part of a language compiler, such as the runtimeenvironment or a managed framework on the computing device 100. Method300 includes defining a plurality of type modifiers for controllingaccess to members through references pointing at an object at 302. Oneof the type modifiers is associated with each type name at 304. Anaspect of defining a plurality of type modifiers includes defining adifferent access permission that restricts operation on the object at306. When used with a type or isolated method, the type permissionrestricts what can be done to an object graph to which it points. Thetype permissions include at least two isolation modifiers at 308, suchas “immutable” and “mutable,” to control access to members throughreferences.

In one example, three isolation modifiers are used including“immutable,” “read,” and “write” at 310. (More than three isolationmodifiers are also contemplated to restrict what can be done with theobjects.) An immutable reference points at an object possibly-sharedamong concurrent threads, but the state accessible through this modifieris statically proven not to change. A read reference also points to anobject possibly-shared among concurrent threads, but no concurrentwrites are permitted while such read references exist. In one example,this can include immutable access as well as reads of mutable fields. Awrite reference points either at an object that is not concurrentlyshared with another thread or at a shared object that has been providedwith exclusive access so that writing can be done safely by the holderof such a reference.

A more particular example of the immutable-read-write permissionsincludes immutable-only, read-only, and read-write. An immutable-only(i) permission can be used only to read from immutable members. Theobject can be freely shared across threads and accessed concurrently,and the object will not incur concurrency issues. A read-only (r)permission can be used to read from any member, including mutablefields. The object may be unshared, or some form concurrency safety maybe in place to allow concurrent reads. For example, a read lock can beheld by a thread or some static control over references will cause themember to be free from concurrent writes. Or an object with read-write(w) permissions can be shared as read-only (r) across a fork-joinbarrier with structured data parallel constructs. A read-write (w)permission can be used to write to any member, and can include memberswith mutable fields. Some form of concurrency safety is in place toallow the writes. For example, an exclusive lock can be held, or theobject is confined within a single thread.

The isolation permissions can make use of immutable fields in animperative programming language. An immutable type is one wherepost-construction changes are not possible. One example used toestablish an immutable type in an imperative language is the creation ofsupport for “initonly” fields. An “initonly” indicates that variableassignment can only occur as part of the declaration or in a staticconstructor in the same class. An initonly field is one that is notwritten to once the object on which that field resides has been fullyconstructed. In this context, fully constructed means the constructer ofthe object has finished executing. Imperative languages can include atype system support that verifies this property, such as with the CommonLanguage Runtime, and reject programs that do not adhere to the rules.An example of support for initonly fields includes “readonly” in the C#programming language.

Each occurrence of a type “T” can be associated with one of thesemodifiers in many numbers of ways. In one example, the notation T:x, isused where x is one of the isolation modifiers. In an example of threeisolation modifiers, x can be: i=immutable-only, r=read-only, andw=read-write. For simplicity, the example notation T:x is usedthroughout the disclosure, but it is contemplated that other notationscan be used. A program can specify an isolation modifier in any contextwhere a type is to be named. Examples in a universal syntax, i.e.,without regard to any specific programming language, using the notationT:x include:

a formal parameter declaration: void f(T:x foo) { . . . }.

a local variable declaration: void f( ) {T:x foo; . . . }

a field (state or instance) declaration: class C {private T:x m foo; . .. }

a generic type parameter: class C<T> { . . . } void f( ) {C<T:x> foo; .. . } as well as others. Arrays can also be denoted as such, e.g. T:x[]:y.

In one implementation, the default access modifier is immutable orimmutable-only (i) so that an unadorned type T is equivalent to T:i. Ofnote is that the isolation regions map to program scopes, however, andthat program code outside of the isolation region can ignore thepermission annotations in some implementations. This can serve tobroaden the application of the isolation permissions as well a providinga runtime that is legacy friendly for existing code. In oneimplementation, static variables of type T cannot be “T:i” because thestatic variables are shared. In pass-by-value, the compiler copies thevalue of an argument in a calling function to a correspondingnon-pointer or non-reference parameter in the called functiondefinition. The parameter in the called function is initialized with thevalue of the passed argument. As long as the parameter has not beendeclared as constant, the value of the parameter can be changed. But thechanges are only performed within the scope of the called function only.The changes have no effect on the value of the argument in the callingfunction.

In one implementation, the permissions are additive. For example, write(w) implies read (r), and read (r) implies immutable (i). In otherwords, T:w is effectively equivalent to T:irw, and T:r is effectivelyequivalent to T:ir. Thus, permissions can be removed safely, where T:wimplicitly coerces to T:r, and T:r implicitly coerces to T:i. Thus, (w)can be considered a stronger permission than (r), or (r) is weaker than(w). Further, when a weaker reference is used to retrieve a strongerreference, the stronger reference is coerced to the weaker permission.For example, reading a U:w reference from an object reached via a T:ireference yields a U:i.

With the isolated permissions, concurrency safety can be extended tomethods with an “isolated” method modifier, which indicates that theisolated method respects the isolation permissions. In one example, codeof an isolated method “M” follows the isolation permissions. Forinstance, mutable fields in the type may not be read or written to for(i) references and may not be written to for (r) references. In someexamples, M will not call non-isolated methods or invoke non-isolateddelegates. During method or delegate invocation, M supplies actual inputparameters that have the same or stronger permissions as theircorresponding formal parameters. M supplies actual output (byref)parameters with permissions that are identical to the correspondingformal parameters during method and delegate invocations because byrefscan be used for reading and storing. M stores references that are accesscompatible with the target storage location type such as if the storagelocation has the same or weaker permission than the source reference.Further, when M overrides a virtual method or implements an interfacemethod, (1) all input (non-byref) parameters have the same or weakerpermissions than the member declaration formals; (2) all byrefparameters have identical isolation modifiers, and (3) the return typeincludes a permission modifier that is the same or stronger than thepermission modifier of the return type of the member declaration. Withthese rules, M does not reveal references that may violate isolationpermissions and thus access permissions remain valid for an entiremethod callgraph.

The following pseudo code is used as an illustration:

class C { private T:w m_f; public C( ) { m_f = new T( ); } publicisolated:r T:r Get ( ) { return m_f; } public isolated:w void Set(T:wobj) { m_f = obj; } }

The field m_f is marked with a T:w permission, and receives and storesvia the “Set” method objects that have T:w permission. Any exposure ofthe internal object is done with a T:r permission via the “Get” method,and this is possible because T:w implicitly coerces to T:r. Thenotational convention of “isolated:x” is used to denote the hidden“this” argument of the method has the permission x, so in the example“Get” operates with “this:r” and “Set” operates with “this:w.”Non-isolated methods can ignore access modifiers. Code at the boundaryof the non-isolated code and isolated code coerces unadorned “T”references such that they include the appropriate permission modifiers.

An “isolated” delegate type “D” binds to an “isolated” method “M” whereinput and output parameters are access compatible with the delegateparameter. Establishing isolated delegates is similar to (but reversed)overriding virtual methods and implementing interface methods asdescribed above. More particularly, input (non-byref) parameters can bestronger than the parameters of the target, byref parameters matchpermissions, and return type parameters can be weaker than theparameters of the target.

For example, given a method “isolated void M(C:r c)” the followingdelegate types are evaluated as whether they are legal to bind againstthe method:

-   isolated delegate void A(C:w c); // Legal as strengthening.-   isolated delegate void B(C:r c); // Legal as precise.-   isolated delegate void C(C:i c); // Illegal as weakening.

Generics are also capable of respecting modifiers. For example, considera generic delegate “isolated delegate U IsolatedFunc<T, U>(T e);” theactual parameters for “T” and “U” determine the methods it can binditself to:

EXAMPLE 1

isolated C:r M(C:r c); . . . IsolatedFunct<C:r, C:r> a = M; // Legal asprecise. IsolatedFunct<C:i, C:r> b =M; // Legal as strengthening theinput (covariance). IsolatedFunct<C:r, C:i> c + M; // Legal as weakeningoutput (contra-variance). IsolatedFunct<C:w, C:i> c = M; // Legal asboth

EXAMPLE 2

isolated static C:r M(C:r c); . . . IsolatedFunct<C:i, C:w> c = M;//Illegal as co- and contra-variance are opposite.

Language authors are provided with the decision as to whether to supportcovariant and contra-variance similarly to overrides of methods as notedabove.

During member access, the permissions of the contained expression typeare combined with declared access permission of the member. For example,given a member access “o.M” where “o” is a reference of type “T:x” and“M” has a declared type of “U:y,” the type of statement “o.M” will beU:min(x, y) where the resulting reference is no stronger than theweakest permission of the combination. In other words, given a T:xreference, any field U:y or value returned from a method U:y are morphedinto U:min(x, y) such as:

{T:w+U:r}=U:r

{T:r+U:w}=U:r

T:w+U:w=U:w

These rules provide permissions granted to a single reference will alsoapply to the object graph reachable for that reference. For the exampleof a “Customer” type:

class Customer { puplic Order:w_order = ...; }and an instance from a context of read access:

-   Customer:r c= . . . ;    These rules provide that no writes to the_order are allowed:-   c._order._total= . . . ; // error:_order is erased to Order:r, not    Order:w    In another example, the system permits the ability to suppress    checks for a region of code to enable preferred side-effects.

Byrefs—such as “out” and “ref” parameters—to fields are similar with theexception that the resulting type will become U&:min(x, y) instead ofU:min(x, y). The “&” in this instance means “reference to a ‘U’[reference].” This byref rule protects against a possible elevation ofprivilege with a common practice of avoiding copying by accessing valuetype fields through byrefs.

The system further includes an ability to constrain generic typeparameters. For example in the case where System.Object contains amethod ‘void isolated:r Equals(object:r other)’. If we write a List<T>class that checks two objects for equality (perhaps as part ofimplementing a ‘bool isolated:r Contains(object:r obj)’ method), itdeclares that T is at least readable, which can lead to:

-   T: immutable-   T: immutable+-   T: readable−-   T: readable-   T: readable+-   T: writable−-   T: writable

Accordingly, the type system support for memory isolation permissionsdescribes how to create regions of program scopes of isolated memory. Asmentioned above, a “write” reference points either at an object that isnot concurrently shared with another thread or at a shared object thathas been provided with exclusive access so that writing can be donesafely. In certain circumstance, however, fine-grained concurrent accessin the regions is desired, which introduces concurrent access. Readpermissions can safely erase all concurrent access, but read permissionsdo not provide for concurrent mutation.

An abstraction called an IsolatedObjectGraph<T> can be built using thetype system support described in FIG. 3 to provide for safe concurrentmutations of isolated object graphs and represents a fully isolatedobject graph. The IsolatedObjectGraph<T> uses the type system toencapsulate an entire object graph that is rooted by an instance of typeT. The graphs can be fully generic as to the type permissions, and caninclude an immutable graph, a readonly graph, or fully mutable graph, orthe like. The encapsulated object graph does not contain references toobjects outside of the object graph, objects outside the graph do notcontain references to objects within, and the desired properties arestatically provable and can enable safe parallel mutation of objectgraphs. In one example, an imperative framework provides for staticallyproving the object graph to be isolated. Objects within the object graphcan be run, read, and/or written, and the object graph can be staticallyproven to continue to be isolated. One example use of theIsolatedObjectGraph<T> is for constructs such as parallel foreach (orFor-Each) loops or other safe data parallel operations.

FIG. 4 illustrates a public interface of the IsolatedObjectGraph<T> 400.The IsolatedObjectGraph<T> includes a constructor 402 and supports thecombinators, or methods, of Enter 404, Extract 406, Replace 408,ReplaceFrom 410, and Compute 412 to interact with the object graph. Theconstructor 402 accepts a factory function that creates and returns theobject root. This constructor runs in a context where only immutablestate from the outside world is available, thus ensuring that the statereturned must have been created by the function, and moreover iscompletely isolated. The Enter method 404 permits state to be read andoptionally mutated from within the region. It also runs in an immutablecontext, so it cannot store any portion of the state anywhere, nor canit save references to objects outside of the graph within. The Extractmethod 406 permanently takes the state from the region. The Replacemethod 408 replaces the state in the region with state created by aprovided function. The function is given access to the state currentlyinside the region, the replaced state can be a transformation of thestate and is not a copy. The ReplaceFrom method 410 safely removes statefrom another IsolatedObjectGraph<T> and replaces and replaces thecurrent state with it. The ReplaceFrom method 410 allows sidewayscopying to make possible storing state into a region from a locationother than the region. The Compute method 412 provides access to thestate and ability to return an immutable reference out of the region.The reference can point directly to a selected portion of the objectgraph, which is safe because the reference is immutable and thereforestate modifications cannot be seen or induced via it.

An example definition of this type illustrated in FIG. 4 can bedescribed as:

public class IsolatedObjectGraph<T> { public isolated:wIsolatedObjectGraph(FactoryFunc<T> factoryFunc) { m_state =factoryFunct( ); } public isolated:r void Enter(EnterAction<T>enterAction) { return replace(_ => default (T)); } public isolated:w TReplace(ReplaceFunc<T> replaceFunc) { T oldState = m_state; m_state =replaceFunc(oldState); return oldState; } public isolated:w TReplaceFrom(IsolatedObjectGraphic<T>:w other) { return Replace(_ =>other.Extract( )); } public isolated:r U Compute<U>(ComputeFunc<T, U>computeFunc) where U:I { return computeFunc(m_state);  } } publicisolated:i delegate T FactoryFunc<T>( ); public isolated:i delegate voidEnterAction<T>(T state) public isolated:i delegate ReplaceFunc<T>(T:roldState); public isolated:i delegate U ComputeFunc<T, U>(T:r state)where U:i;

The constructor 402 and its associated factoryFunc delegate (of typeFactoryFunc<T>) are implemented as invoking the delegate provided andstores the result into the m_state field. The constructor 402, however,is marked with as isolated:w, which causes it to execute in an isolatedregion and has write permissions to its own object fields. The delegatetype FactoryFunc<T> as an isolated delegate binds to isolated methodsthat execute within isolated regions. The delegate is marked isolated:iand binds itself to static methods or instance methods that haveimmutable access to the this reference. The method merely allocates newstate, manipulates it, and eventually discards some of it and returnssome of it. The method does not store the state.

The theme is continued with the other methods. For example, the state isnot read directly from the graph. In order to subsequently interact withthe state, an EnterAction is passed to the Enter method 404. As withFactoryFunc, the EnterAction delegate binds to other isolated:i methodsso the EnterAction delegate does not keep a record of the state passedto it with the Enter method 404.

The Extract method 406, a single time operation, is used to extract thestate. Once extracted, the object graph can be freely manipulatedbecause the object graph will not be placed back into the region. TheReplace method 408 provides for the generation of a new state to beplaced back into the region. Much like FactoryFunc, ReplaceFunc executeswithin an isolated region and does not keep a record of any state.

The Compute method 412 provides for the computation of some state thatis made available outside of the isolated method. This state in theexample is of a type U that is immutable as it is indicated as U:i. Evenif T and U represent the same base type, the state made availableoutside of the isolated region is immutable and will not be mutablethrough the use of this reference. States that are subsequently mutatedinside the isolated region are not made available outside the region.

FIG. 5 illustrates a method 500 of the type illustrated in FIG. 4. Themethod permits a state to be read from an isolated region at 502. Thestate is then taken from the region at 504. The state taken from theregion is replaced with another state, which was created from a providedfunction at 506. The method also allows removal of a state from anotherIsolatedObjectGraph<T> and replaces the current state with the statefrom the another IsolatedObjectGraph<T> at 508. The method then returnsan immutable reference from the region at 510. It is contemplated thatthe method can be performed without type permissions.

The data structure described above enables safe mutation of objectgraphs in parallel. For example, given a Set<T> type that has uniqueelements, a ParallelForEach construct that accepts aSet<IsolatedObjectGraph<T>:w> can be declared and can concurrentlyinvoke the Enter method 404. Within the delegate supplied, state can bechanged, for example, with:

-   public void ParallelForEach<T>(Set<IsolatedObjectGraph<T>:w>r    source, EnterAction<T> action);

In the limit, ParallelForEach can enter each IsolatedObjectGraph<T> inthe set at once, including one per processor in the computing device 100with standard static and/or dynamic partitioning techniques.

Even though the implementation of this method is unsafe dynamically(because it introduces concurrency), all code leading up to the call isstatically verified through a runtime compiler 136, such as the commonlanguage runtime (CLR) in the .NET framework. Further, all user-suppliedcode invoked with the ParallelForEach is also statically verified. Themethod is safe when (1) the Set<T> correctly verifies dynamicuniqueness, (2) the partitioning algorithm does not assign duplicateelements to separate dynamic threads, and (3) each element of the set isa statically isolated object graph. This will reduce the scope ofdynamic verification of safety to the implementation of Set<T> andParallelForEach, both of which are normally trusted system components.

Although specific embodiments have been illustrated and describedherein, it will be appreciated by those of ordinary skill in the artthat a variety of alternate and/or equivalent implementations may besubstituted for the specific embodiments shown and described withoutdeparting from the scope of the present invention. This application isintended to cover any adaptations or variations of the specificembodiments discussed herein. Therefore, it is intended that thisinvention be limited only by the claims and the equivalents thereof.

What is claimed is:
 1. A method of providing state isolation in a dataparallel operation, the method comprising: defining a plurality ofpermissions with corresponding modifiers to control access to membersvia references pointing at objects of the operation, the permissionsincluding: an immutable permission in which an immutable referencepoints at an object shared between concurrent threads of the operationbut state is proven not to change; a read permission in which a readreference points at an object shared between concurrent threads in whichthere are no concurrent writes; and a write permission in which a writereference points at an object that is at least one of not shared betweenconcurrent threads and includes exclusive access in which a write to thereference is done with safe concurrency; encapsulating an object graphto an isolation region with a permission of the plurality ofpermissions; and implementing the object graph with a compiler such thatmutations of state within the object graph are not made availableoutside of the isolation region to enable a safe data parallel operationwithin the object graph.
 2. The method of claim 1 wherein the pluralityof permissions are type permissions.
 3. The method of claim 2 whereinthe corresponding modifiers are type modifiers.
 4. The method of claim 3wherein an unadorned type is an immutable permission.
 5. The method ofclaim 1 wherein the data parallel operation is an isolated method. 6.The method of claim 1 wherein the state accessible through the immutablepermission is statically proven not to change.
 7. The method of claim 1wherein the state accessible through the read permission includesimmutable access and reads of mutable fields.
 8. The method of claim 1wherein the state accessible through the write permission is read-writeto a member.
 9. The method of claim 1 wherein the plurality ofpermissions are extended to methods.
 10. The method of claim 9 whereinthe permissions bind to delegates.
 11. A system to provide stateisolation, the system comprising: memory to store a set of instructionsand receive a data parallel operation; and a processor to execute theset of instructions and the data parallel operation to: define aplurality of permissions with corresponding modifiers to control accessto members via references pointing at objects of the operation, thepermissions including: an immutable permission in which an immutablereference points at an object shared between concurrent threads of theoperation but state is proven not to change; a read permission in whicha read reference points at an object shared between concurrent threadsin which there are no concurrent writes; and a write permission in whicha write reference points at an object that is at least one of not sharedbetween concurrent threads and includes exclusive access in which awrite to the reference is done with safe concurrency; encapsulate anobject graph to an isolation region with a permission of the pluralityof permissions; and implement the object graph such that mutations ofstate within the object graph are not made available outside of theisolation region to enable a safe data parallel operation within theobject graph.
 12. The system of claim 11 wherein the encapsulated objectgraph includes a generic type parameter.
 13. The system of claim 11wherein the permissions state what a recipient of the reference can dowith the object.
 14. The system of claim 11 included in a managedenvironment.
 15. The system of claim 11 wherein the object graph isimplemented with a language compiler.
 16. A computer readable storagedevice to store computer executable instructions to control a processorto: define a plurality of permissions with corresponding modifiers tocontrol access to members via references pointing at objects of theoperation, the permissions including: an immutable permission in whichan immutable reference points at an object shared between concurrentthreads of the operation but state is proven not to change; a readpermission in which a read reference points at an object shared betweenconcurrent threads in which there are no concurrent writes; and a writepermission in which a write reference points at an object that is atleast one of not shared between concurrent threads and includesexclusive access in which a write to the reference is done with safeconcurrency; encapsulate an object graph to an isolation region with apermission of the plurality of permissions; and implement the objectgraph such that mutations of state within the object graph are not madeavailable outside of the isolation region to enable a safe data paralleloperation within the object graph.
 17. The computer readable storagedevice of claim 16 wherein the object graph is implemented in a languagecompiler.
 18. The computer readable storage device of claim 17 whereinthe language compiler is an imperative programming language.
 19. Thecomputer readable storage device of claim 16 wherein the plurality ofpermissions apply an immutable field.
 20. The computer readable storagedevice of claim 16 wherein the permissions are applied to at least oneof a type and isolated method.